…ublish failures

- kars --version was hardcoded to 0.1.0-alpha.1 and drifted from the
  published package version. Read it from package.json via createRequire
  so it can never drift again (works in both dist/ and src/).
- Bump @kars-runtime/cli to 0.1.1. The manually-published 0.1.0 lacked a
  README and provenance and npm forbids overwriting it; 0.1.1 lets CI
  publish a complete, provenance-signed version via OIDC.
- Harden the release workflow npm-publish step: pre-check for an existing
  version (skip cleanly) and emit a loud ::warning:: annotation on a
  genuine publish failure, so a 'green but did not publish' outcome is
  visible in the run summary instead of being silently swallowed by
  continue-on-error.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… v* tags

Both legacy workflows triggered on the same clean v[0-9]+.[0-9]+.[0-9]+
tags as the new release-public-interim.yml (the single public release
pipeline), causing guaranteed failures on every public tag:

- image-sign-sbom.yml targets karsacr.azurecr.io and fails on
  azure/docker-login with 'Input required: username' because the
  ACR_USERNAME/ACR_PASSWORD secrets don't exist (MCR not onboarded yet).
- release.yml creates a bare GitHub Release for the tag, colliding with
  the richer signed release that release-public-interim.yml creates for
  the same tag.

Make both dispatch-only so they no longer auto-fire on v* tags. Public
release images are signed via keyless cosign on GHCR in the canonical
pipeline; image-sign-sbom.yml can be dispatched manually once ACR creds
are provisioned.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>